Drilling rigs (for instance, those involved in hydrocarbon exploration and production) are acquiring increasing amounts of drilling data. Users of these drilling rigs and the companies interested in their operation typically use a combination of computer programs or processes and human intelligence to analyze the drilling data and combine it with previously recorded or stored historical data (and/or data from external databases) to control the drilling rigs; make decisions about current drilling activity; and/or to plan future exploration and production programs (that is, drilling programs).
The gathered drilling data includes, but is not limited to, surface-based measurements about the rigs' equipment (such as hook load, block height, rotary RPM etc.); measurement while drilling (MWD) operational data (including measurements such as down-hole torque, gamma ray, resistivity, etc.); borehole trajectory survey information; vessel positioning and cable tensioning data; mud logs; lithology reports; operational reports; and any other data having a bearing on the condition of the drilling rigs, wells, their operations, etc.
Lately, the advent of “wired pipe” is increasing the amount of data transmitted from down-hole locations. Moreover, because of the increasing availability of WANs (Wide Area Networks) such as the Internet, over which such data can be shared, users of such drilling data are finding ways to exploit the data with an expanding number of computer programs and each other. However, as disclosed herein, certain issues peculiar to drilling data (for instance data homogeneity and data heterogeneity) threaten to derail sharing of such data even as its availability soars. And, of course, the drilling data produced in these systems possesses some value and typically users want to preserve it and safeguard it from unauthorized tampering, spying, etc.
Traditional well-planning, drilling and geo-steering decision programs, wellbore stability analysis and prediction programs, and other programs related to exploration and production efforts also typically suffer from problems associated with single purpose programs. For instance, a user might realize a need or desire for a new program, write the code, deploy it to a processing platform, and begin its execution. In writing these programs, the user typically includes express designations in the code for the locations of their inputs, outputs, and other resources. Even when a similar new program is desired for deployment elsewhere, the writing of the new program includes again identifying, locating, and expressly designating the locations of the new inputs, the new outputs, and other resources which the new program is to use in its new environment.
Of course, sometimes desired functionality might suggest that the new program needs an input from another program. In such cases, the user must identify that other program and arrange some mechanism to ensure that this particular data is updated and available when needed. Sometimes, though, the user fails to provide that mechanism or the mechanism fails anyway. As a result, unpredictable operation of the new program occurs. These programs therefore often fail, “hang up,” crash, etc. thereby frustrating their very purpose and, of course, interested users. In addition, because the users expressly coded the resource addresses needed for these programs, they cannot readily be re-used and are therefore effectively single-purpose programs. A need or desire for multiple versions of these single-purpose programs (e.g., a copy for each drilling rig in a company) aggravates the situation since each copy must be manually re-written despite similarities between the underlying subject matter (e.g., the drilling rigs).
Moreover, the needed data often originates at one point and is shared at some other point (or points). Typically, in such point-to-point data sharing schemes, the user must manually locate the logical, and sometimes even the physical, location of the source data and must manually identify the desired location for the processed results. Any mistake along the way can lead to unpredictable behavior of the programs depending on such resources. Moreover, deliberate attempts might be made to access or alter data for which the subject user has no access rights.
Discussing a more specific situation will illustrate other shortcomings of previously available single-purpose, point-to-point programming approaches. Take for instance, a previously available wellbore-stability system that connects over a network to a particular drilling rig's porosity measurements; computes the wellbore's condition; stores the results; displays real-time visualizations thereof; and issues an indication if the results indicate that an off-nominal condition might exist. To write such a program, each source of data involved in the stability calculation must be manually identified and each storage location, display location, etc. must also be manually identified. Furthermore, if any of that input data originates with other single-purpose programs, all of those single-purpose programs must be identified. Plus, mechanisms must be created to ensure that they execute before the new dependent program.
Similarly, a single-purpose geo-steering system can connect in a point-to-point manner with a source of a wellbore's current measured depth, azimuth, and inclination; calculate the wellbore's trajectory; store and display the results thereof; and issue an indication of the wellbore trajectory (whether nominal or off-nominal). Again, a user must manually and correctly identify the physical and logical source of the input data and of the targets for the various outputs. Moreover, the user must do so even when that data might not be stored (or otherwise available) where the user expects it to be and/or where the targets might have moved. In addition, the user must ensure the proper order of execution of all programs involved.
Many applications in the drilling domain follow a similar pattern. A user manually connects a hard-coded program which resides at one point to a point source of drilling data; manually confirms the data source(s); the routing of the outputs and the functioning of the program; and then leaves the new program running, hopefully with the right input data and right output locations updated and available at the correct times. In other words, the user configures the program in a point-to-point fashion and often incidentally constrains the program to a single purpose. While single-purpose and/or point-to-point configurations might be useful for a limited number of such situations, they become wasteful of the user's time after the setup of even a few such programs. In light of the hundreds (thousands, etc.) of possible programs to be performed on drilling data, point-to-point and/or single-purpose programs are too cumbersome and error-prone for practical or efficient use.